1. Field of the Invention
The present invention relates generally to peer-to-peer remote copy (PPRC) or Flash Copy (FC) data storage technology, and specifically, to methodology for deactivating the ability to establish new PPRC or FC relationships between devices via in-band commands after initialization of the disaster recovery configuration is complete.
2. Description of the Prior Art
Peer-to-Peer Remote Copy (“PPRC”) is a hardware-based disaster recovery solution designed to maintain a mirror image of application data at a remote secondary location. Particularly, key to PPRC, is the migration of data sets from mass storage devices, such as hard disk drives or other data storage media, to another set with a minimum of disruption to the applications using the data. Particularly, Peer-to-Peer Remote Copy (PPRC) mechanisms automatically copy changes that are made to a source (primary) volume to a target (secondary) volume until the PPRC relationship is suspended or terminated.
FIG. 1(a) depicts, in general, a PPRC system 10 showing a primary Enterprise Storage System 15 including a primary production Enterprise Storage Server (ESS) 17 and a host server 20 running a host application that reads and writes data to the primary ESS 17. The primary ESS 17 is linked to a secondary ESS storage system 25 including a remotely located secondary backup 27 and corresponding remote back-up host server 30 via an Enterprise Systems Connection (“ESCON”) connection 45. In current configurations, the enterprise connection 45 comprises a high-speed link, supporting, for example, 2-Gigabit-per-second (Gbps) Fibre/FICON data transfer rates, however, other ESS system configurations implementing other high-data rate connectivity are applicable. As known, peer-to-peer remote copy solutions comprise functionality for enabling direct and synchronous copying of data at the volume level from the primary ESS 17 to the secondary backup ESS 27. As known, the PPRC solution for direct copying of data is transparent to the operating system of the primary ESS and any applications running on the primary hosts, however, there is a performance impact on application I/Os.
FIG. 1(b) depicts a Storage Service Provider (SSP) 50 that provides PPRC storage solutions for primary sites depicted by host servers 60a, . . . , 60n where the production applications run. The storage service provider includes primary Enterprise Storage Server (ESS) 77 that receives production data from the servers 60a, . . . , 60n, via respective Input/Output (I/O) or in-band links 65a, . . . , 65n for storage in a set of volumes 80. Particularly, host server requests for data content storage are initiated via system/server user interfaces over in-band links (e.g. ESCON, FICON, FCP).
A PPRC relationship is established with a secondary ESS or recovery site ESS 87 having volumes 85 onto which the production data is mirrored by PPRC over peer-to-peer links 90 connected by ESCON host adaptors (not shown). As shown in FIG. 1(b), a workstation 92 providing a configuration interface 95 is connected to each of the primary and secondary ESS storage systems 77, 87 via respective out-of-band links 97, 98.
A further ESS storage function is referred to as FlashCopy which provides a point-in-time (PiT) copy of a logical volume, also called T0 copy, with almost instant availability for the application of both the source and target volumes. Only a minimal interruption is required for the FlashCopy relationship to be established, so the copy operation can be initiated. The copy is then created by the ESS, with minimal impact on other ESS activities. FlashCopy may also be used in conjunction with either the local or remote copies of data created by PPRC, making it easy to create additional copies for rapid recovery following application errors or for other uses. FlashCopy is invoked at volume level taking into account the following considerations: 1). The source and target volumes must have the same track format; 2). The target volume must be at least as large as the source volume; 3). The source and target volumes must be within the same ESS logical subsystem (LSS); and 4). A source and a target volume can only be involved in one FlashCopy relationship at a time.
It is known that one use of FC is for backing data up to tape. The data on tape must be “consistent”, therefore writes to the data cannot be allowed during the backup. Since many shops require 24/7 data access, FC can be used to make a copy of the data, which copy is then backed up to tape.
It is additionally understood that the FC and PPRC can be used in combinations to achieve additional functions. For example, a PPRC pair may be suspended (due to a hardware failure) and a PPRC Resync is desired. During the PPRC Resync, the secondary is not in a “consistent” state until the Resync finishes, therefore if the Resync fails, the secondary is not usable. If a FC of the PPRC secondary is made before the PPRC Resync is started, a “consistent” secondary copy is always available.
As soon as a FlashCopy establish command is issued (either invoked by a TSO (Time Sharing Operation) command, or by means of the ESS Copy Services Web user interface (WUI) (Configuration GUI) command, for example, the ESS establishes a FlashCopy relationship between the target volume and the source volume. This relationship exists from the time a FlashCopy operation is initiated, until the ESS copies all data from the source volume to the target volume. Optionally a FlashCopy may be requested not to execute the background copy, in this case the relationship must be specifically withdrawn in order to terminate it.
There are basically three stages that a FlashCopy relationship goes through: Establishing the relationship (Phase 1), then copying the data (Phase 2), and finally terminating the relationship. During the establish phase of the FlashCopy relationship, a metadata structure is created for this relationship. This metadata is used by the ESS microcode to map source and target volumes as they were at the time when the FlashCopy was requested (T0 copy), as well as to manage subsequent reads and updates to the source and target volumes. Updates to the source volume after the FlashCopy relationship is established will not be reflected on the target device. The establish process takes a minimum amount of time. As soon as the relationship is established, user programs have access to both the source and target copies of the data. With the relationship already established, and the source and target volumes already available for the applications to use them, the copy phase (Phase 2) begins. How this copy phase is conducted depends on the copy option that is selected for this FlashCopy operation. The FlashCopy relationship may be established either with or without background copy. FlashCopy will manage the copy process differently according to a specified option.
When multiple customers share disk controllers to meet their PPRC needs, security is a primary concern for the Storage Service Providers (SSP). That is, when customers (via host servers 60a, . . . , 60n) generate in-band copy commands, they may effect integrity of an established PPRC relationship, i.e., effect the state of a remote volume and data contents written thereto.
Since existing PPRC establish commands (without the restrictions) are accepted and executed, customer data remains at risk if a PPRC establish command is issued.
It would thus be highly desirable to provide a mechanism for limiting or restricting execution of remote copy service commands in order to better preserve integrity of data copied to remote storage systems.